是做什么的
ESLint
- JS 代码检测工具
- 静态分析代码，帮助检测格式问题 并 查找代码潜在的问题，比如使用了某个变量却忘记定义
- 可以自动修复
Prettier
- 代码格式化工具，能够统一自己或者团队的代码风格
- 格式化功能与 ESLint 很像，但不检查代码质量
- 除了原生支持的 JS，同时也支持 JSX、Flow、TypeScript、HTML、JSON、CSS 等其他众多语言
- 可以自动修复
EditorConfig
既不检测也不格式化代码
仅仅在开发者团队内部使用的所有 IDE 和编辑器之间 定义了一份标准的代码风格指南（比如：行尾、缩进样式、缩进距离…）
- 比如，一个团队主要使用 Sublime Text 和 VSCode，EditorConfig 能够使得它们在单个文件内定义公共的缩进模式（空格或制表符）
自定义规则
ESLint
.eslintrc.*文件（诸如.eslintrc.json或.eslint.yaml等等）优先级
如果同一个目录下有多个配置文件，ESLint 只会使用一个。优先级顺序如下：
.eslintrc.js.eslintrc.yaml.eslintrc.yml.eslintrc.json.eslintrcpackage.json
同prettier插件一样，eslint插件默认会首先遵循离当前文件最近的.eslintrc.*文件中的配置，如果这个文件的同级或者更上几级的目录中没有.eslintrc的配置文件，此时运行eslint命令或者使用插件才会使用settings.json中的配置。
Prettier
.prettierrc.*文件
EditorConfig
.editorconfig- 实际上会覆盖任一 IDE 或编辑器的配置
为何三个工具可以共用
问题一
为什么 ESLint 有代码格式化能力，还需要 Prettier？
代码检查工具（linters）的两类规则
- 格式化规则：防止代码风格不一致 & 避免丑陋的代码风格（比如：
max-len最大长度,no-mixed-spaces-and-tabs不允许空格和tab混合,keyword-spacing关键字的spacing,comma-style冒号风格 等等） - 代码质量规则：防止无用和错误代码（比如：
no-unused-vars不能有未使用的变量,no-extra-bind不能有无意义的bind,no-implicit-globals不能隐式定义全局变量,prefer-promise-reject-errors不能在promise中reject()空值 等等）
ESLint 能够应用这两类规则，如果可以的话，它还能自动修复代码。另一方面，Prettier 只能检查代码中的格式错误，但是它却比 ESLint 更专业。
问题二
使用 Prettier 后，既然 Prettier 已经能够不需要编辑器的配合格式化代码，为什么还需要 EditorConfig？
EditorConfig 的作用是配置你的编辑器，以便你所编写的代码已经是格式良好的了，而 Prettier 要做的则是格式化你已经编写的代码。与 Prettier 相比，EditorConfig 可用于更多的语言和项目。
使用 EditorConfig 还可以避免 Prettier 在代码保存时做无用功，因为编辑器已经根据 EditorConfig 的规则做了格式化的工作。
不过，令人感到棘手的是确保 Prettier 和 EditorConfig 具有相同的规则，而不必在两个单独的文件中重复配置。